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Abstract 

This paper further introduces and formaUzes a novel concept of self-forensics for automotive ve- 
hicles, specified in the Forensic Lucid language. We argue that self-forensics, with the forensics taken 
out of the cybercrime domain, is applicable to "self-dissection" of intelligent vehicles and hardware 
systems for automated incident and anomaly analysis and event reconstruction by the software with 
or without the aid of the engineering teams in a variety of forensic scenarios. We propose a formal 
design, requirements, and specification of the self-forensic enabled units (similar to blackboxes) in 
vehicles that will help investigation of incidents and also automated reasoning and verification of 
theories along with the events reconstruction in a formal model. We argue such an analysis is benefi- 
cial to improve the safety of the passengers and their vehicles, like the airline industry does for planes. 

Keywords: self-forensics, specification. Forensic Lucid, event reconstruction, forensic computing, 
autonomic computing 

1 Introduction 

In this work we apply a novel concept of self-forensics to vehicle design allowing vehicle's subsystems to 
analyze themselves forensically as needed and preserve the forensics data for further automated analysis 
in the cases of failures, crash, and event reconstruction. 

We insist this should be a part of the protocol for for each new vehicle design, to monitor its hardware 
and software components. 

Problem Statement. It may become relatively difficult-to-impossible to do event reconstruction in 
testing and crash incident analysis e.g. to determine a faulty component or any other internal cause of 
crash if a vehicle in question is badly damaged. Even if some of information may be available at the 
incident scene to the investigators, including eyewitness stories and the actual final state of the vehicle, it 
may never be clear what was the reason (other than the external evidence), so ad-hoc conclusions can be 
incorrectly inferred from what the investigators can see as well as the eyewitness stories of the exterior 
to the accident. 

Proposed Solution. We propose to include a notion of self-forensic components included into the 
hardware and software design of the modern cars. Their purpose is multi-fold. They can serve as the 
real-time monitoring and logging and analyzing subsystems of critical vehicle parts and overall health 
as well as measuring parameters such as as speed, temperature, etc. over safety-predefined thresholds 
in a durable blackbox-like device in a Forensic Lucid format (with a possibility of external export via 
wireless communication) with the intent of in-situ automatic analysis and reasoning response as well 
as for after-the-fact for the purpose of event reconstruction to be complete based on the self-forensics 
journals automatically with tools making sure no event is missed and the analysis is thorough. The 
approach, combined with an expert system, can also be used to train personnel in such investigative 
techniques. It would also allow to pin-point a potential cause of the fault inside rather than external 
allowing to more precisely hold someone accountable. 
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Organization. First, we introduce the notion of forensic computing, the Forensic Lucid language, the 
self-management properties of autonomous systems, etc. as a background and the related work to give 
the reader the idea for this work in Section|2] Then we overview the notion of self-forensics Section[3]and 
its application to the vehicle safety design with the purpose of automated reasoning during the activity 
as well as preservation of he evidential data for later analysis and event reconstruction using automated 
tools. We go over requirements, limitations, advantages and examples. Then, we conclude and present 
some future work items in Section |4] 

2 Background and Related Work 

2.1 Forensic Computing 

The notion of computer forensics also known as cyberforensics or the associated /ore«5/c computing has 
been traditionally associated with computer crime incidents investigations HUH. We show the approach 
is useful in vehicle crash investigations and event reconstruction. 

Further we argue if the new technologies are built with the self-forensics software and hardware 
toolkits or components, it would even help the automotive industry to improve the safety design of the 
vehicles and implement decision-making modules when real-time event analysis may lead to catastrophic 
or similar outcomes or during crash testing of new vehicles. 

The notion of self-forensics was first proposed by Mokhov f3l for autonomous systems such as 
NASA spacecraft as well as large- and medium-scale distributed software systems that need to support 
themselves and analyze themselves with the new self-forensics autonomic property. 

2.2 Self-Management Properties 

The notion of self-management and self-managed systems comes from autonomic computing (AC) 111151. 
The common aspects of self-managing systems, such as self-healing, self-protection, self-optimization, 
self-configuration and the like are now fairly well understood in the literature and R&D ll6ir7ll8ll9l[T0l. 
We formally introduce another autonomic property that we call self-forensics that we would like to be a 
part of the standard specification for vehicle systems specification. 

2.3 Forensic Lucid 

Forensic Lucid ifTTl [Til [T3l is a forensic case specification programming language for automatic de- 
duction and event reconstruction of computer crime incidents. The language itself is general enough to 
specify any events, their properties, duration, as well as the context-aware system model. We take out 
Forensic Lucid from the cybercrime domain for its eventual application to aid the vehicle crash incidents 
investigation from within as an example of self-forensic case specification. 

Forensic Lucid is based on the Lucid |[T4l [T5l IT6l [TTl [TSl language and its various dialects that 
allow natural expression of various phenomena, inherently parallel, and most importantly, context-aware, 
i.e. the notion of context is specified as a first-class value in Lucid |[T9l l20l [211 . Lucid dialects are 
functional programming languages. All these properties make Forensic Lucid an interesting choice for 
forensic contextual logging and computing in crash investigations related to the internal failures of the 
components. 

Forensic Lucid is also significantly influenced by and is meant to be a usable improvement of the 
work of Gladyshev et al. on formal forensic analysis and event reconstruction using finite state automate 
(FSA) to model incidents and reason about them ll22l|23l . 
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While Forensic Lucid itself is still being finalized as a part of the PhD work of the author along with 
its compiler, run-time and development environments, and the accompanying expert system, it is well 
under way to validate its applicability to various use-cases and scenarios LI 3., 24 J . 

Context 

Forensic Lucid is context-oriented. The basic context entities comprise an observation o in Equation [T] 
observation sequence os in Equation|2j and the evidential statement in Equation|3] These terms are inher- 
ited from II22II23I and represent the context of evaluation in Forensic Lucid. An observation of a property 
P has a duration between [min,min + max] (where min is the minimum duration of the observation, max 
is a potential variation from that minimum). This was the original definition of o [22, 23] and the author 
later added w to amend each observation with weight factor or probability or credibility to later further 
model in accordance with the mathematical theory of evidence f25l . f is an optional timestamp as in a 
forensic log for that property. An observation sequence represents, which is a chronologically ordered 
collection of observations represent a story witnessed by someone or something or encodes a description 
of some evidence. All these stories (observation sequences, or forensics logs, if you will) all together 
represent an evidential statement about an incident. The evidential statement is an unordered collection 
of observation sequences. The property P itself can encode anything of interest - an element of any 
data type or even another Forensic Lucid expression, or an object instance hierarchy or an event. It can 
be arbitrary "deep" in what it can contain as a set of observer computations, state transitions, complex 
objects, outcomes, measurements, etc. 

o = (P,f,min,max,w) (I) 

OS = {oi,...,On} (2) 

es = {osi,...,os,„} (3) 

Having constructed the context, one needs to built a transition function \f/ and its inverse The 
generic versions of them are provided by Forensic Lucid ^TT\ based on ||23l l22l . but the investigation- 
specific one has to be built, potentially visually (e.g. using a data-flow graph programming tool that 
can translate into Lucid and back |26]), by the engineering team, which can be done even before the 
vehicle starts, if the self-forensics aspect is included into the design from the start. The specific 
takes evidential statement as an argument and the generic ^ ^ takes the specific ^ ^ as an argument as 
in functional programming. 

When the run-time system, such as the General Intensional Programming System (GIPSY) ll27l l28l 
|29l |30l . evaluates a Forensic Lucid specification, navigating the evidential statement context of eval- 
uation using intensional operators |[T2]| . it traces the execution of the and computes the possible 
backtraces of the events from the final observed state of the incident back to the known initial state of the 
vehicle. The forensic evidence collected as a context for ^' ^ is compared against a potential hypothesis 
statement, or a witness (can be device or a sensor or an eyewitness) account to see if they agree, and if 
they do, what are the possible explanations in the backtraces. The backtraces, if exist, are ordered from 
the most credible to the least credible (after computing the aggregated credibility score). The investiga- 
tor is then presented with backtraces of the processed evidence (that can be a large bulk to sift through 
manually) representing the reconstructed events. If there are no such backtraces, then the witness claim 
or say manufacturer specification of a faulty component, do not agree with the evidence, which may 
reasonably provably mean that component is is the cause of the incident or that eyewitness is lying or 
the component specification is not what it claims to be. It is also possible that we do not have enough 
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evidence in our knowledge base that we acquired from the incident - in this case the investigator would 
normally know where to look for more evidence or question more witnesses, etc. 

3 Self-Forensics Requirements for Vehicle Design and Incident Investiga- 
tion 

In this section we elaborate in detail on the application of self-forensics and its requirements that must 
be made formal, if the property to be used in the industry. 

Existing self-diagnostics, computer BIOS reports, and S.M.A.R.T. lOTl reporting for hard disk as 
well as many other devices could be a good source for such forensic data computing, i.e. be more 
forensics-friendly and provide forensics interfaces for self-forensics analysis and investigation as well as 
allowing engineering teams extracting, analyzing, and reconstructing events using such data. The process 
has to be supported by the related languages, and tools available to the investigator to model the case, 
import the actual forensics data gathered, and validate claims and hypotheses of what happened against, 
potentially large and vast volumes of data, potentially automatically preprocessed with a backtrace of the 
event reconstruction. 

This would be even a greater enhancement and help with the blackboxes, like in planes in the airline 
industry, or reasoning about events, possibly speeding up the analysis of the anomalies in subsystems. 

Most, if not all new cars and other automotive road vehicles these days all have on-board computers 
and often GPS devices. This by default reduces the cost of adding of the self-forensics units to the design 
and development of hardware and software components of such vehicles. 



3.1 Application 

The self-forensics property is meant to embody and formalize all existing and future aspects of self- 
analysis, self-diagnostics, data collection and storage, and real-time automatic decision making if neces- 
sary that were not formalized and categorized as such before and define a well-established category in 
the industry and academia. In that view, self-forensics encompasses self-diagnostics, blackbox record- 
ing, (Self-Monitoring, Analysis, and Reporting Technology) S.M.A.R.T. reporting [31], and encoding 
this information in analyzable form of Forensic Lucid contextual logging for in situ or later automated 
analysis and event reconstruction using the corresponding software tool or tools. 

Optional parallel logging of the forensics events during the normal operation of the road vehicles, 
especially during "extreme" periods of operation, i.e. when it is detected that the speed, internal fluid 
pressure in any fluid lines, temperature, etc. are over some minimal soft safety threshold, the granularity 
and frequency of reporting may increase can go off-vehicle via a wireless link to a cell tower or via 
peer-to-peer ad-hoc mobile wireless network of vehicles |[32ll to eventually be stored say at the same 
company that provides the GPS or cellular service to this particular vehicle or its driver. Shipping such 
forensics logs off-site will have a duplicate copy in case the original gets damaged in the incident. It can 
also be used by a more powerful computer at the company to do a near real-time analysis of the vehi- 
cle's performance and alert the driver if anything anomalous is detected and predicted to be potentially 
harmful. 

To achieve that all electric, electronic, and mechanical subsystems of a vehicle can have functional 
units to observe them other for anomahes and log them appropriately for forensics purposes. 
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3.2 Training 

Such forensic specification is also useful to train new engineers on a safety design and testing team, 
and others involved, in data analysis, to avoid potentially overlooking data and making incorrect ad-hoc 
decisions. 

There are well known log search engines or real-time vulnerability scanners and detectors that, if 
adapted to our case, would allow the investigator searching and even analyzing the multiple logs or 
even real-time situation, and even co-relate some events, based on the timestamps, etc. e.g. such as 
Splunk f33\ and Nessus f34l, adapted for the use in a vehicle's on-board computer, yet if applied to our 
case they would still be tedious and time consuming to work with by an investigator when examining the 
logs and detected evidence, that could be very numerous. 

In an Forensic Lucid-based expert system (that's what was the original purpose of Forensic Lucid 
in the first place in cybercrime investigations) one can accumulate a number of contextual facts from 
the self-forensic evidence and the trainees can construct their theories of what happened and see of 
their theories agree with the evidential data. Over time, (unlike in most cybercrime investigates) it can 
accumulate the general enough contextual knowledge base of encoded facts that can be analyzed globally 
and on the web. The data can be shared across manufactures and mechanical and software engineers 
involved. 

3.3 Requirements 

Here we briefly define the requirements scope for the self-forensics property adapted to road vehicle 
design: 

• Should be optional if constrained by the budget, but should be strongly recommended to be in- 
cluded. Must not be optional for mission critical and safety-critical road vehicles (e.g. military, 
police, ambulance, fire trucks, etc.). 

• Must be included in the design at all times. 

• Must cover all the self-diagnostics events mentioned earlier as well as any design-specific events 
and monitoring. 

• Must have a formal specification (that what it makes it different from just self-diagnostics). 

• Must have tools for automated reasoning and reporting about incident analysis matching the spec- 
ification. 

• Context should be synthesized in the terms of system specification involving the incidents, e.g. 
parts and the software and hardware engineering design specification should be formally encoded 
(e.g. in Forensic Lucid). 

• Preservation of forensic evidence must be atomic, reliable, robust, and durable. 

• The forensic data must be able to include any or all related non-forensic data for analysis when 
needed, including measurements taken around the time of incident or even the entire trace of a life- 
time of a system component logged somewhere for automated analysis and event reconstruction. 

• Levels of forensic logging and detail should be optionally configurable in collaboration with other 
design requirements in order not to hog other activities, create significant overhead, or fill in the 
bandwidth of the wireless connection or log storage. 
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• Event co-relation optionally should be specified. 

• Some forensic analysis can be automatically done by the vehicle's computer itself (provided having 
enough resources to do so). 

3.4 Limitations 

The self-forensics autonomic property is very beneficial to have for automated analysis of incidents in 
road vehicles and the like, but it probably can not be mandated as absolutely required due to a number of 
limitations it creates. However, whenever the monetary and time budgets allow, it should be included in 
the design and development of the road vehicle parts or software systems capable of self-monitoring and 
reporting of encoded forensic data. 

Here are some most prominent limitations: 

• The cost of the vehicle will obviously increase from manufacturing, to maintenance, and the end- 
user buying price. 

• If built into software, the design and development requires functional long-term storage and CPU 
power. 

• Likely increase of bandwidth requirements; if the more than twice bandwidth and storage used. 

• An overhead overall if collect forensics data continuously. Can be offloaded along with the control 
data. 

• Ideally should be in ROM or similar flash type of memory; but should allow firmware and software 
upgrades. 

• Current computer logging within vehicles are not designed to be for the work presented here - 
Forensic Lucid-based self-forensics analysis, so there will have to be an effort to adapt it if Forensic 
Lucid specifications become an industry standard. Fortunately, traditional existing logging can 
be converted to use the Forensic Lucid expressions without much difficulty, that would greatly 
simplify forensic analysis of such data. 

• We do not tackle other autonomic requirements of the system assuming their complete coverage 
and presence in the system from the earlier developments and literature, such as self-healing, self- 
protection, etc. 

• Transition function y ^rid its inverse has to be modeled by the engineering team through- 
out the design phase and encoded in Forensic Lucid. Luckily the DFG IDE ||26ll . like a CAD 
application is to be available. 

• Manufacturers or some external certifying agency has to be involved to make sure the self-forensic 
components function as intended to prevent the manufacturer to circumvent self-incriminating 
evidence thereby promoting the quality and accountability of vehicle manufactures. 



3.5 Advantages 

Having Forensic Lucid helps scripting the forensics events in a log in the road vehicle's computer or a 
blackbox. The blackbox can contain the forensic data encoded anyhow including forensics expressions, 
XML, or just compressed binary and using external tool to convert it to a Forensic Lucid specification for 
further evaluation by investigators. Forensic Lucid is context-aware, built upon the intensional logic ll35l 
[36]| and dialect that existed in the literature and math for more then 30 years. 
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3.6 Small Example 

• Self-forensic hardware sensors observe systems (electrical and mechanic) of a road vehicle. 

• Every engineering event is forensically logged. 

• Each forensic sensor may observes several systems or subsystems. 

• Each sensor composes a "story" of an observational sequence a particular system or a component 
in as a Forensic Lucid context and the component specification is known at the manufacture time 
and encoded as a Forensic Lucid specification in advance. 

• A collection of sensor witness stories from multiple sensors, properly encoded, represent the evi- 
dential statement. 

• An incident happens; engineers define theories about what happened. The theories are encoded 
as observation sequences. When evaluated against the evidential statements from all sensors the 
events are co-related and reconstructed according to the Forensic Lucid semantics. 

Then the evaluating system (e.g. GIPSY) can automatically verify the theory automatically against 
the context of evidential statement and if the theory T agrees with the evidence, meaning this the- 
ory has an explanation within the given evidence (and the amount of evidence can be significantly 
large for "eyeballing" it by humans), then likely the theory is a possible explanation of what has 
happened. It is possible to have multiple explanations and multiple theories agreeing with the evi- 
dence. In the latter case usually the "longer" (in the amount of events and observations involved) 
theory is preferred or the one that has a higher cumulative weight/credibility w. 

4 Conclusion and Future Work 

We would like to conclude with the remarks that we stated at the beginning - that the self-forensics 
modules and components, both hardware sensors, a simpler analogue of a blackbox, and software com- 
ponents should be included into the modern road vehicle design for real-time and post-mortem forensic 
log data analysis in the Forensic Lucid-encoded form to aid investigation and event reconstruction with 
the formal approach to make the investigation complete not only from the outside, but also from the 
inside by using the forensics data. Furthermore, such data can be used during the crash testing of the 
road vehicles by the manufacturer as well as to train the engineering teams and the investigators to do a 
more complete analysis with an aid of the Forensic Lucid-based expert system. 

We also discuss the potential limitations of the approach. In our future work we will attempt to 
address the limitations as well as complete some other intermediate items along the way, specifically. 

Future Work. 

• Estimate the feasibility of "back-porting" the self-forensics modules and components into the ex- 
isting fleets of road vehicles as well as the costs of storage and maintenance of such data, when it 
expires, and who has a control over it. 

• Amend the Autonomic System Specification Language (ASSL) |l37l|38l[39l|40l to handle the self- 
forensic property along with its formal specification and verification. 

• Implement the notion of self-forensics in the GIPSY |l27l|28l|2l|30l|4ll and DMARF ll42l l43l l44l 
|45ll systems the author is closely working on. 
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• Finalize implementation of the Forensic Lucid compiler and the development and run-time envi- 
ronment. 

• Implement large realistic cases encoded in Forensic Lucid to test and validate various aspects of 
correctness, performance, and usability. 

• Industrialize and standardize the concept in the industry. 

• Resolve and map out privacy issues with external reporting of the forensic evidence via the wireless 
transmission and the applicable laws. 

• Durability. 

• Cost analysis of the self-forensic system deployment in a road vehicle. 

• This research can aid crash investigations not only in automotive vehicles, but technically in all 
vehicle types, e.g. in the aviation industry by incorporating the self-forensics features and compo- 
nents into helicopters, planes, etc. to aid crash investigations such as B6ll47]| . 
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